Remote Desktop (CuriouserLabs)

An internal Windows Remote Desktop client — a friendlier replacement for the built-in Remote Desktop Connection (mstsc.exe). Save the hosts you connect to as clickable tiles, optionally remember the password, and reconnect in one click. Built with Tauri 2, React, and TypeScript.

Connections require the corporate VPN, exactly like mstsc today.

What it does

• Saved connections — add a host by its computer name (e.g. L-abc123-SD) and it appears as a tile. Click the tile to launch the session.
• Saved credentials (optional) — tick Save password and it's stored in Windows Credential Manager (DPAPI-protected, never in plaintext). Because it's stored under TERMSRV/<ComputerName>, mstsc reads it automatically and connects without prompting. With no saved password, mstsc prompts as usual.
• Username — leave it blank to use your logged-in Windows account, or set an explicit user, DOMAIN\user, or user@domain per connection.

Under the hood the app generates a standard .rdp file and launches the OS client mstsc.exe with it — so the session itself is the same trusted Windows Remote Desktop experience.

How it works

Concern	Approach
Launching a session	Generate a .rdp in %TEMP%\remote-desktop\, sign it, and run mstsc.exe
Storing connections	JSON file in the app config dir
Storing passwords	Windows Credential Manager via the windows crate (CredWrite/Read/Delete) at TERMSRV/<host>
Signing .rdp files	rdpsign.exe with a configured certificate thumbprint (see below)
Deploying module JARs	Copy over WinRM (PowerShell Remoting) using the host's saved credential

Replacing module JARs (deploy)

A common task is swapping a JBoss module's JAR on a server and restarting to test it. The app can push the JAR for you — no RDP session needed, since the copy runs over WinRM (PowerShell Remoting) using the same credential mstsc uses.

1. Configure modules — click Modules in the header and add each module as a name + the full remote path of its JAR (including the file name), e.g. C:\jboss\modules\com\acme\billing\main\billing-core.jar. These live in modules.json in the app config dir and are shared across hosts.
2. Deploy — on a connection tile, click Deploy JAR, pick the module and a local .jar, and upload. The app backs up the existing remote file to a timestamped *.bak, copies the new JAR in, and verifies the size.
3. Restart JBoss — for now, restart the service from the Windows Services app (services.msc). Automating the restart is the planned next step.

Requirements: WinRM must be reachable on the server (domain-joined servers with Kerberos/Negotiate over 5985 work out of the box), and your account needs write access to the module path. If the host has no saved password, the deploy dialog prompts for one.

RDP file signing (the "Unknown remote connection" warning)

The April 2026 Windows security update (CVE-2026-26151) makes mstsc.exe show a consent dialog every time it opens a .rdp file. When the file is unsigned, it's the red "Caution: Unknown remote connection / Unknown publisher" variant — and that variant has no "don't ask again" option, so it reappears on every connect. (Typing a host directly into Remote Desktop Connection is unaffected, which is why the built-in client doesn't show it but a file-launching client like this one does.)

The app removes the warning by signing each generated .rdp with rdpsign.exe before launch, using a certificate that Windows trusts as an .rdp publisher. Signing is best-effort: if it isn't set up (or rdpsign fails) the connection still launches — you just see the warning again.

First-run setup (automatic)

On first launch the app provisions the signing certificate itself — no manual step. In a background thread it creates a self-signed code-signing certificate, trusts it for your account (CurrentUser Root + TrustedPublisher), registers it as a trusted .rdp publisher (HKCU policy), and records its thumbprint at %APPDATA%\com.curiouserlabs.remote-desktop\signing.json. It needs no admin rights.

You'll see a one-time Windows prompt to trust the certificate — click Yes. After that, connections are signed and the warning is gone. (If the cert is ever removed, delete signing.json and relaunch to re-provision.)

The same logic is also available as a standalone script — useful for pre-seeding machines or re-running manually:

powershell -ExecutionPolicy Bypass -File scripts\Setup-RdpSigning.ps1

Managed / domain-joined machines

On a locked-down machine, per-user settings can be overridden by machine Group Policy and a self-signed root may be disallowed. In that case use a certificate from your corporate CA (or a public CA) and have IT push the equivalent machine policy under HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services:

• AllowSignedFiles (DWORD) = 1
• TrustedCertThumbprints (REG_SZ) = the certificate thumbprint(s), uppercase, semicolon-separated

then set signing.json to that certificate's thumbprint.

Diagnosing a warning that won't go away — open the dialog and read the Publisher line:

• Still "Unknown publisher" → the file isn't being signed. Check that signing.json exists with a thumbprint and that the cert is in Cert:\CurrentUser\My (the first-run prompt may have been declined).
• Shows the publisher name but still prompts → signing works, but the trust isn't taking effect. On a managed machine that almost always means machine Group Policy overrides the per-user AllowSignedFiles/TrustedCertThumbprints (or blocks the self-signed root). This needs the machine policy above and a CA-issued cert from IT — a per-user self-signed cert can't win against it.

Fallback (not recommended)

To temporarily revert to the pre-April-2026 behavior machine-wide, an admin can set RedirectionWarningDialogVersion (DWORD) = 1 under HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client. Microsoft flags this as temporary (a future update may remove it) and it weakens phishing protection, so prefer signing.

Prerequisites (development)

• Windows 10/11 with WebView2 runtime (preinstalled on current Windows)
• Rust (stable) and Node.js 18+
• Visual Studio Build Tools with the Desktop development with C++ workload

Development

npm install
npm run tauri dev      # run the app with hot reload

Build a Windows installer

npm run tauri build

Installers are written to src-tauri/target/release/bundle/ (NSIS .exe and WiX .msi).

Customising the app icon

Replace the default icons by running:

npm run tauri icon path/to/logo.png   # 1024x1024 source PNG

Phase 1 verification checklist

Run these on a machine connected to the VPN:

1. Launch the app; add a connection with a real server computer name.
2. Click the tile → mstsc opens and prompts for the password → session connects.
3. Edit the connection, tick Save password, enter the password, save.
4. Click the tile again → connects without a password prompt.
5. Edit again, untick Save password, save → the credential is removed (next connect prompts again).
6. Delete the connection → tile disappears and any saved password is purged.
7. Run scripts\Setup-RdpSigning.ps1, then click a tile → connect without the "Caution: Unknown remote connection" warning. (Before setup, expect the warning; the app still connects.)
8. Open Modules, add a module with a real remote JAR path. On that host's tile click Deploy JAR, pick a local .jar → it uploads, backs up the old file (*.bak next to it on the server), and reports success. Restart JBoss via services.msc and confirm the new JAR is live.

See PHASE1_PLAN.md for the full plan and design decisions.